Connector for Oracle Directory Server

This section of the documentation contains technical specification about the connector for Oracle Directory Server that is implemented to link ASM Core and Oracle Directory Server. It describes the details of the third-party application, that is, Oracle Directory Server including:

  • The name of the .NET assembly file
  • Connection methodology
  • The resource and link types that can be discovered on the application
  • The attributes of each resource and link types that can be imported into Service Manager version Configuration Management Database (CMDB).

For compatibility and version support details, refer to the ASM Connector Matrix.

You should familiarize yourself with the information in Installing Connectors before installing any connectors, and read the Integration topics for more information on how to configure them.

Use Case Scenario

Directory servers, such as Oracle Directory Server, store information about an organization’s users in groups and organizational units. ASM Core person entities are defined as person records. These persons can act as Users, analysts, or both. Organizations that use ASM Core may want to synchronize these sources to import users from directory servers into ASM Core as persons.

The table below presents an integration scenario based on the connector for Oracle Directory Server.

Scenario An organization maintains a list of all its employees in Oracle Directory Server. The groups are configured in Oracle Directory Server based on the department to which an employee belongs. One such group in Oracle Directory Server is the Help Desk group.
Goal The organization intends to import all users classified under the Help Desk group into ASM Core as analysts.
Action The connector for Oracle Directory Server is installed, the source is created, the resource type mappings are set up, the Oracle group is specified and the Oracle users are imported in ASM Core as persons.

Connector Description

The connector for Oracle Directory Server is part of the base kit of ASM Core. As soon as it is installed, the connector is available for configuration and use from the Integration menu. Therefore, there is no need to proceed with its installation.

This connector must be scheduled.

The table below provides a description of the connector for Oracle Directory Server.

Information fields

Name

Connector

LDAP Oracle <-> ASM Core

Third-party application

Oracle Directory Server

Assembly

Infra.Connector.LDAP.Sun.dll

Connector class

SunConnector

Configuration file

Infra.Connector.LDAP.Sun.icnf

Connection methodology

LDAP v3, by using Microsoft .NET System.DirectoryServices library

Connection Parameters

The table below provides a description of the Oracle Directory Server connection parameters.

Parameters

Description

LDAP Server Path

 

The full LDAP path of the directory server, incorporating:

  • Protocol, usually LDAP://

  • This URL is only valid if Integrated Security is disabled for your system.

  • Server
  • Portal number (optional)

  • This URL is only valid if Integrated Security is disabled for your system.

  • Root naming context

Expanded examples:

Server Bind

LDAP://myldapserver.mydomain.com/dc=mydomain,dc=com

Server-less Bind

LDAP://dc=mydomain,dc=com

Using custom port no 80389:

LDAP://myldapserver.mydomain.com: 80389/dc=mydomain,dc=com

User DN/ID

 

User DN/ID must be a distinguished name, for example, CN=User 1, DC=mydomain, and so on.

If this is not provided, the connector will use the credentials of the executing accounts. In this case, it will use the credentials of web server and Integration service. Ensure that both these accounts have appropriate rights.

Password

Provided

Server Bind

Checkbox

Select this option if the connection string provides a specific server for optimal performance.

Do not select this option for server-less connection strings.

Use SSL

Checkbox

Indicates that communication should use SSL.

The connector for Oracle Directory Server and other LDAP connectors permit users on one source to be members of groups on other sources, scheduled within the same integration schedule. When a group member is found, their distinguished name is used to ascertain to which source they belong to. Only sources with a defined root naming context are considered for selection. The user is associated with the source with the longest root naming context contained at the end of the user’s DN. Root Naming Assessment provides more information.

The Update Date field in the information section of the person record shows the date of the last update in the ASM database and not the last date the user had modified in Oracle Directory Server database.

Resolve Functionality

The Resolve functionality is a functionality that can be accessed through the Federated CMDB Integration Platform when setting up mappings between third-party resource fields and ASM Core fields.

Oracle Directory Server allows specifying a manager value for every user. The Resolve functionality handles this particular Oracle Manager field in the following way:

  • Background: One Oracle Directory Server user possesses one Oracle Directory Server Manager.
  • Expected operation: In the context of the connector for Oracle Directory Server, the Resolve capability allows the importation of both user and its manager, and also the creation of a link between them. In case, the manager cannot be found or imported or if it is not mapped, then the Resolve functionality would resort to a default user-defined value for the Manager field in the ASM Core user record.
  • The Manager field is not a default field in Oracle. Administrators need to activate this Oracle attributes in case the Resolve function is to be used during the importation process.

Miscellaneous

Although it is possible to customize the Oracle Directory Server schema so that a unique user can have several managers, this aspect is not handled by the Resolve functionality.

Licensing

Contact Sales for more information.

The connector for Oracle Directory Server is not a licensed software. This means that every User can use it free of charge.

Oracle Directory Server Base Mapping

Person records in ASM Core must be created with a minimum set of fields populated. The table below lists the recommended base field mappings that administrators should configure for all person mappings from Oracle. The left-hand column reflect the current field names as viewed in ASM Core.

ASM Core person field

Oracle Directory Server user field

Login ID

Login ID

User Qualified Name

User Principal Name

Surname

Surname

First Name

First Name

Background

Description

Email ID

Email

Telephone

Telephone

Job title

Job Title

 

LDAP authentication over SSL (LDAPS) to the Oracle Directory Server

ASM Core has the ability to communicate to LDAP servers by using the SSL protocol. For this communication to succeed, the following must be taken into account:

  • Ensure that the keys are certified, properly signed, and stored in the appropriate category within the certificate store of the operating system.
  • Some third-party tools may allow communication through SSL without the following additional configurations. However, ASM Core's reliance on this particular library forces the user to adhere to these steps.

If these conditions are not met, the connection will not be established without any clear indication of reason. The message Server is not operational will be displayed in the Eventlog.

On the Oracle Directory Server

ASM Core uses a standard library of .NET, System.DirectoryServices. In order to use it, ensure that the correct root certificate is installed in the right place on the Oracle server.

  • Create and Export the certificate to the servers.

  • When creating the Root Certificate, Oracle administrators should ensure that the value entered in the Common Name field is the fully qualified domain name of the Directory Server.

  • Install the root certificate.

 

Root Certificate Installation for IIS

  1. Click Windows Start > Run and type mmc.
  2. Click File > Add/Remove Snap-in.
  3. In the Add/Remove Snap-in window, click Add .
  4. In the Add Standalone Snap-in dialog box, select Certificates from the list of Available Standalone snap-ins and then click Add .
  5. In the Certificate Snap-in dialog box, select Computer Account and then click Next.
  6. In the Select Computer dialog box, select Local Computer and then click Finish.
  7. Close the Add Standalone Snap-in dialog box and click OK in the Add/Remove Snap-in dialog box.
  8. Right-click Trusted Root Certification Authorities and select All Tasks > Import .
  9. In the Certificate Import Wizard, click Next .
  10. Browse and select the root certificate that you intend to import and then click Next.
  11. After the import process is over, click Finish. The root certificate is now installed. Ensure that the root certificate appears under Trusted Root Certification Authorities.

The Certificate Installation: Installing your IIS SSL certificate in Microsoft IIS guide provides detail of the certificate installation.

Resource Types

The connector for Oracle Directory Server allows for exposure and importation of users and their properties as follows:

  • User: The generic information on Oracle Directory Server users is given in the table below.

    • Information fields

    Description

    Mapped to

    objectClass=user

    objectCategory=person

    Description

    Represents a user stored within Oracle Directory Server

    Must be received by Group

    True

  • Group types: The Group concept is used to classify the Oracle Directory Server users into different categories. For example, one group for development, another group for documentation and so on. These groups can be of two types: Group and OU (Organizational Unit) as shown in the table below.
  • When importing Oracle users, the particular group from which you intend to import the users must be specified:

    • Group type

    Object class

    Group

    objectClass=group

    OU

    objectClass=organizationalunit

  • Schema: The schema is the list of attributes that are available for each individual Oracle user. The table below provides the list of schema and its description:

    • Name displayed

    Data type

    Mapped to Oracle property

    Object GUID

    string

    GUID

    Common Name

    string

    cn

    Last Modified

    dateTime

    modifytimestamp

    Surname

    string

    sn

    First Name

    string

    givenName

    Description

    string

    description

    Login ID

    string

    uid

    User Distinguished Name

    string

    dn

    Email

    string

    mail

    Employee No

    string

    employeeNumber

    Postal Address

    string

    sa

    Postal Address Line 1

    string

    sa1

    Postal Address Line 2

    string

    sa2

    Postal Address Line 3

    string

    sa3

    Telephone

    string

    telephoneNumber

    Fax

    string

    facsimileTelephoneNumber

    State

    string

    s

    Country

    string

    co

    Post/Zip Code

    string

    postalCode

    Job Title

    string

    title

    Room No

    string

    roomNumber

    Locality

    string

    l

    Cell

    string

    Mobile

    Department No

    string

    departmentNumber

    Office

    string

    physicalDeliveryOfficeName

    Organization

    string

    o

    Organization Unit Name

    string

    ou

    Manager

    entityReference

    manager

Link Types

No link types are defined for the connector for Oracle Directory Server.

Resolve Functionality: Additional Information

The Resolve functionality allows for a user-defined default value to be used if no matching records are found when trying to resolve a specific person field value. Several reasons can lead to an unsuccessful resolving attempt. Amongst the most common are:

  • They belong to a different domain and that domain is not configured — Oracle Directory Server integration supports cross-domain references assuming all referenced domains are configured.
  • They do not belong to a mapped group.
  • They are excluded by user-configured mapping.
  • Imports are regulated. So, the corresponding user records are not automatically created until a user intervenes through Federated CMDB Admin.

Root Naming Assessment

Can groups and users who are members of the groups belong to different domains?

Yes. There are several requirements for this to work:

  • All domains that the target users and groups belong to must have a corresponding directory server defined in ASM Core.
  • All domains involved are required to be a child domain of a common parent or have a parent-child relationship.

Example of Root Naming Assessment

Assume that there are three directory servers configured:

  1. LDAP://server1/dc=mydomain,dc=com
  2. LDAP://server2/dc=sub1,dc=mydomain,dc=com
  3. LDAP://server3/dc=sub2,dc=mydomain,dc=com

Against server 2, the following group is mapped:

Group1, DN: cn=Group1,dc=sub1,dc=mydomain,dc=com

This group has two members:

  • User1, DN: cn=User1,dc=sub1,dc=mydomain,dc=com
  • User2, DN: cn=User2,dc=sub2,dc=mydomain,dc=com

ASM Core associates User1 with server 2 because the server 2 root naming context is the longest naming context contained at the end of User1’s DN. Although the trailing part of server 3’s root naming context also concludes the user’s DN, it is not considered because not all of the naming context is included. Although all of server 1’s root naming context is found at the end of the user’s DN, server 2 is given preference because its root naming context is longer.

Similarly, User2 is associated with server 3 and not server 2 because there is no match, and not server 1 because server 3’s root naming context is longer.